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A KNOWLEDGE-BASED SYSTEM FOR LP MODELING 



Daniel R. Dolk 
Naval Postgraduate School 

1 . INTRODUCTION 

The focus of this paper is on linear programming (LP) software in the 
context of model management and decision support. As a result, we will not 
be interested in the algorithmic properties of LP or math programming (MP) 
codes, but rather their applicability to more generalized modeling environments 
wherein models can be linked or decomposed in a manner which frees tne user 
from having to know the internal representation which the algorithms require. 

In particular, we will look at the objectives and functions of a generalized 
model management system and how these require a knowledge-based modeling 
capability. We will then describe a partial implementation of a knowledge- 
based modeling system for LP models called the Generalized experimental Math 
Programming system (GXMP). 

2. LP AND MODEL MANAGEMENT 

Most, if not all, LP software has operated on the assumption that users know 
enough about their model to select the correct package to use to obtain a 
computer solution. In the decision support environment, the user, in fact, 
may not be aware of what models are needed or available to solve the problem 
at hand. In this case, it becomes the task of the model management system to 
orchestrate the appropriate models and data to solve a user-described problem 
(Figure 1). 




Figure 1: Role of Model Management in Decision Support 
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In order for an MMS to function in this capacity, it clearly requires 
a knowledge-based capability for representing knowledge about models. The 
following kinds of knowledge should be contained in the MMS, for example: 

1. Which situations particular models are applicable to; 

2. Model integrity statements; 

3. Information required to instantiate a model; 

4. Which solution algorithm(s) to employ to solve a model; 

5. How to link models to other models; 

6. How to decompose models into submodels; 

7. Interpretation of model results. 

In addition to knowledge representation and storage, an MMS must also 
have one or more generalized problem-solving or inferencing capabilities for 
manipulating the knowledge. This "reasoning" capability should encompass 
heuristic as well as deterministic reasoning so that, for example, the MMS 
can pattern-match user-supplied problem descriptions with- available model and 
data instances. The first order predicate calculus has been suggested as one 
means of representation (Bonczek et al , 1981) which is well-suited for deter- 
ministic kinds of inferences. Semantic networks have been considered to support 
more heuristic kinds of reasoning within a modeling environment [Elam et al , 
1980). The GXMP system is based on the concept of knowledge abstractions, or 
in the case of modeling, model abstractions (Dolk, 1982; Konsynski and Dolk, 
1982), a knowledge representation scheme which attempts to combine the strengths 
of deterministic and heuristic inferencing (Dolk, 1982). 

A model abstraction consists of three parts: data objects, procedures 

acting upon those objects, and assertions or facts (knowledge) concerning the 
relationships between data objects and procedures (Figure 2). For MP models, 
data objects correspond to constraint equations and model parameters, procedures 



3 



DATA OBJECTS 



(Ex: Constraint Equations, 

Index Sets) 



PROCEDURES 

(Ex: Add-Constraint-Model, 

Modify- Index-Set- Value, 
Linear (Equation)) 



ASSERTIONS 

(Ex: Linear (Constraint), 

Linear (Obj-Func)) 



Figure 2. Model Abstraction Structure 



are operators which act upon the data objects (ADD-CONSTRAINT-TO-MODEL, e.g.), 
and assertions specify integrity conditions ("constraints must be linear in an 
LP model ," e.g. ) . 

A modeling system with a knowledge-based capability alters the traditional 
view of modeling software (Figure 3). Typically, math programming software has 
been algorithmically oriented wherein the input data are prepared by the user- 
modeler and fed into a "black box" program which applies the algorithm to supply 
the results. Knowledge about the models is supplied externally by the modeler 
in preparing the input and internally by the programmer in specifying the 
algorithm. In neither case is this knowledge accessible to other users who see 
only the input and the "black box." In the knowledge-based modeling system, 
however, this structure is expanded to abstract the knowledge pertinent to a 
model into a separate data component of the system. Furthermore, the algorithms 
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(a) Traditional Modeling Software System 



INPUT 



PROCEDURE 

LIBRARY 



? 

V 



A 

h 



KNOWLEDGE 

BASE 



7 , 


REASONING 




MODEL 


t ** 


PROGRAM 




PROGRAM 



(b) Knowledge-Based Modeling System 



t 

V 



OUTPUT 



Figure 3. Difference Between Traditional and Knowledge-Based 
Modeling Systems 



are stored as data in a procedure library to be used by the reasoning module in 
constructing a model program to solve the problem described by the user. For 
those familiar with rule-based expert systems, the knowledge base would consist 
of rules expressed in a IF <antecedents(s)> THEN <consequent(s)> fashion 
and the reasoning program would correspond to a rule interpreter (Duda and 
Gaschnig, 1981). 
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3. THE GXMP SYSTEM 



The remainder of this paper describes a "first pass" implementation 
of a knowledge-based model management system for LP models called GXMP. Much 
of the effort to date on GXMP has been involved with establishing a suitably 
powerful modeling language for expressing MP models. As a result, the knowledge- 
based capabilities of the system are still very limited. Development phases 
for incorporating these features into GXMP are presented in the concluding 
section. 

Figure 4 shows the salient implementation features of GXMP. The system 
is written in FORTRAN on a Vax- 11/780 using the XMP linear programming library 
(Marsten, 1980) and the ADBMS database management system (Hershey and Messink, 
1975). The overall goal of the GXMP system is to serve as a user-friendly 
virtual machine for LP (and eventually MP) algorithms. Thus, although the XMP 
library was chosen as the source of the simplex algorithm, there is no restric- 
tion on using other algorithms providing they accept input in matrix form. 

The components of GXMP are shown in Figure 5. There are five different 
database types: 

1. The directory catalogs all instances of models, data objects, abstrac- 
tions, and databases currently in the system; 

2. The abstraction database stores model abstractions and serves as the 
knowledge base of the system; 

3. The procedure database stores the subroutines from the XMP library 
including the source code; 

4. The equation database stores an instance of a model expressed in the 
GXMP modeling language; 

5. The parameter database stores the associated numerical parameters of a 
model instance (coefficient and right-hand-side values, e.g.). 

Interface with the user occurs at two levels: a menu dialog for selecting the 

system functions to be performed and a modeling language for expressing LP 
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Model Management System for LP 
FORTRAN 

XMP Library (Marsten, 1980) 

ADBMS (Hershey and Messink, 1975) 
Knowledge-Based (model abstractions) 
User-Friendly Virtual Machine for LP Algorithms 

Figure 4. Features of GXMP Implementation 



DATABASES 

Directory (catalog) 

Abstraction (knowledge base) 

Procedure (XMP library) 

Equation (expressed in modeling language) 
Parameter (coefs, rhs, etc.) 

MENU DIALOG 

MODELING LANGUAGE 

SOLUTION REPORTER 

Figure 5. Components of the GXMP System 



models in a mathematical fashion. The menu dialog accommodates the "naive" 
user wh-ile the modeling language is geared toward the modeler. The solution 
reporter generates LP solutions in terms of the variables which the user 
specifies during model creation. Examples of these various aspects of the system 
are shown in the sample prohlem of the next section. 
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The GXMP modeling language is designed to allow modelers to represent 



expressions in quasi -mathematical notation. It is somewhat similar to FORTRAN 



and contains several key features: 

1. User-supplied variable names in place of mathematical variables (self- 



documenting) : 






Math-Var 


Description 


GXMP-Name 


i 


ci ty 


CITY 


j 


city 


CITY 


X. . 
ij 


shipment from city i 
to city j 


SHIPMENT (i. 


D. 

J 


demand from city j 


DEMAND (j) 



2. Use of inequality signs for expressing constraints. 

3. MIN, MAX, SUM operators. 

4. Use of mathematical indexes in equations. 

5. FOR clause for specifying conditions on indexes and instantiating 
indexes . 



n 

Ex: To express £ X.. = D- for j=l,...,n; joi 

i=l 1J J 



SUM(i) [SHIPMENTS )] = DEMAND(j) 

FOR i OVER CITY, j OVER CITY, i<>j $ 

6. Use of index expressions 

Ex: CONSUMPTION^, t) + INVENTORY(p ,t) - 

INVENTORY(p,t-l) = SUPPLY(p,t) 

FOR p OVER COMMODITY, t OVER PERIOD $ 

Several other syntactical features and restrictions should be mentioned 

1. All indexes must be expressed in lower case and cannot exceed four 
characters in length. Indexes "max" and "min" are reserved names 
(see 4. below). 

2. Simple index expressions of the form <index> <"+" or "-"> 

cinteger or index> are allowed, e.g.: X(i-l,t+l). 

3. Indexes must be used consistently over all equations and each index 
appearing in an equation must be identified in that equation. The 
first restriction states that index i, for example, must be the same 
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in each equation in which it appears. Furthermore, different index 
names cannot be used in different equations to represent the same 
index (unless the index forms a link). The second restriction 
requires identifying an index whenever it appears. This leads to a 
certain amount of redundant specification but results in fully 
documented equations. 

4. Each instance of SUM must be followed by one or more indexes enclosed 
in parentheses and the summand enclosed in square brackets, e.g.: 



is expressed as: i,j J 

SUM (i ,j )[X(i , j )] 

5. Conditions on indexes can be expressed in conjunction with index 
identification, thus we can express: 

0 <= X ( i , j ) <= DEMAND (i,j) fOR i OVER CITY, 

j OVER CITY, i <> j $ 

to indicate that the constraint holds for all i , j except i= j. 
("<>" indicates the "not equal" operator.) The reserved words "max" 
and "min" can be used to refer to the highest and lowest cardinal 
values of an index respectively, thus 

n-1 



can be expressed as: 

SUM ( i , j ) [X ( i , j ) ] FOR i<max, j<max, i OVER... 

6. All decision variables must be grouped onto one side of a constraint. 
Thus if C and F are decision variables: 

C(p,t) + F(p,t) = S(p,t) + F( p , t-1 ) FOR ... 

will not be translated properly and should be rewritten as: 

C(p,t) + F(p,t) - F(p,t-1) = S(p,t) FOR ... 

7. Each unique combination of decision variable and indexes may appear 
only once in a particular equation. Thus the following objective 
function with decision variable DV: 

MAX ( SUM( i , j ) [REV ( i ,j)*DV(i ,j)-EXPNS(i ,j)*DV(i ,j)]). . 
will not be translated properly and should be rewritten as: 

MAX (SUM( i , j ) [ ( REV ( i , j ) -EXPNS ( i , j ) )*DV ( i , j ) ] ) . . 
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Note this restriction does not obviate a decision variable from 
appearing more than once in an equation as long as it has different 
index expressions each time (see sample in 6. above). 



8. Only constraint and objective function expressions are allowed. No 
intermediate expressions may be inserted. This means that although it 
would be convenient to write the objective function above as: 

UNIT-PROFIT(i ,j ) = REV(i,j) - EXPNS(i,j) 

PROFIT = SUM(i ,j)[UNIT-PROFIT(i ,j )*DV(i ,j )]. . . 

MAX (PROFIT) 

it is not currently permitted in the GXMP. 

Only the last point is a serious restriction of the language in any sense, yet' 
it does not pose any conceptual difficulty involving implementation. It was 
imposed primarily to expedite the development time of a "first pass" version 
of the system. 

An example of the language applied to a sample problem is presented in 
the next section. 



4. A GXMP EXAMPLE 

This section presents a simple problem to show how the GXMP operates 
in creating and solving a model. The model we are going to use is the school 
rezoning problem discussed in Hillier and Lieberman (1974, pp. 196-201). The 
gist of the problem is to minimize the distance students need to be bused to 
school while maintaining a specified racial balance in each school. A mathe- 
matical representation is displayed in Figure 6. 

GXMP recognizes three different kinds of parameters: 

1. index sets (i and j in this model); 

2. decision variables (X); 

3. numerical parameters (B, W, S, T); 

Index sets correspond to the indexes in the mathematical representation but 
their values in the GXMP are always character quantities rather than numerical 
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Variable Description 

No. of students in tract i assigned to school j 
Distance from tract i to school j 
No. of black students in tract i 
No. of white students in tract i 
Capacity of school j 

Parameter such that .5-1 £ racial balance _< .5+T 

for i = 1 , . . . ,10; j = 1,2,3 



x o 

D ij 

B i 

W. 



s j 



min T 7 D . . X . . 

1 j 1J 1J 

st y X. . = B . + W . for i = 1 , ...» 1 0 ; j = 1,2,3 

j 1 J 

(all students are assigned to schools) 



y X. . < S. 

5 TJ ~ J 



for i = 1 , . . . ,10; j = 1 ,2,3 



(school capacity not exceeded) 



I (.5-T-W i /(B.+W.))X ij < 0 for i = 1 , 1 0 ; j = 1,2,3 
l (.5-T-B./(B.+W 1 ))X ij < 0 for i = l,...,10; j=l,2,3 



(racial balance) 



x ij i 0 



(nonnegativity) 



for i = 1 , . . . ,10; j = 1 ,2,3 



Figure 6. Mathematical Description of School Rezoning 
Model 
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quantities as in the mathematical case. This significantly increases the 
documentation value of the system. Decision variables are the quantities being 
solved for by the simplex method. Numerical parameters are those quantities 
with numerical values, usually coefficients or right-hand-sides in the 
equations. 

When entering parameters, always enter the index sets first since subse- 
quent parameters will depend upon them. This is done in our example by speci- 
fying TRACT for index i and SCHOOL for index j. For each parameter entered, 
the system will prompt the user for parameter type, data type (not prompted 
for index sets and decision variables), documentation, indexes (if any) that 
the parameter depends upon, and data values to be entered at this time (if any). 

When entering parameters which are indexed, include the indexes as part 
of the name selected ("DISTANCE(i ,j )" for "X 11 for example). The indexes must 
be specified in lower case and cannot exceed four characters in length. They 
must also be used consistently across parameters and equations, i.e. "i" cannot 
refer to TRACT in one case and SCHOOL in another. Neither can “i" refer to 
TRACT in one case and "j" refer to TRACT in another (unless TRACT forms the 
basis of a network problem which is not the case here). The best way to avoid 
confusion is to construct a table that correlates the variables in the mathe- 
matical description with their GXMP counterparts (Figure 7). Once the desired 
parameters have been added to the model, a listing of those parameters can be 
obtained (Figure 8). 

The next step in specifying the model is to enter the objective function 
and the constraints using the modeling language described in the previous 
section. The important rules to remember when entering equations are: 

1. No intermediate expressions are allowed, thus there will be only one 

objective function expression; 
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Model Variable 


Parameter Type 


GXMP Name 


i 




Index set 


TRACT 


j 




Index set 


SCHOOL 


x ij 




Decision var 


STUDENTS (i,j) 


D ij 




Parameter 


DISTANCE (i,j) 


B i 




Parameter 


BLACKS (i ) 


w. 

1 




Parameter 


WHITES(i) 


S J 




Parameter 


SCHOOL-CAPAC(j) 


T 




Parameter 


THETA 


Figure 7. 


GXMP 


Parameter Names for 


School Rezoning Model 


Variables 



2. All parameters appearing in an equation must be defined in the 
parameter database prior to equation entry; 

3. Each separate index appearing in an equation must be instantiated 
in the FOR clause and, like parameter entry, indexes must be used 
consistently across equations; 

4. Summation is expressed by 

SUM(indexl ,index2,. . . )[sunmand] ; 

5. Always end each equation with a . 

Equations are classified as either constraints (CONSTR) or objective function 
(OBJFCN). and assigned an id number as well. If the user does not specify 
an id number when entering an equation, the system will assign one automati- 
cally. Once the equations have been entered, they can be displayed in a 
manner similar to that of the parameters (Figure 9). 
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*Type 


<CR> 


for 


Previous Menu 




1 


for 


Equation Operations 




2 


for 


Parameter Operations 


*/ 


3 


to 


Solve Model 


L. 

*Type 


<CR> 


for 


Previous Menu 


1 


to 


Add Parameter(s) 




2 


to 


Delete Parameter(s) 




3 


to 


Modify Parameters ) 




4 


to 


Specify Values for Parameters 




5 


to 


Link Parameters 




6 


to 


Display Parameters in Model 




7 


to 


Display Parameter Values 



*6 



*Parameter name (20 chars max) 

(If adding, include indexes if any, eg: DEMAND(i,j) 

(Type ALL for all. Hit <CR> to end parameter entry): 



*ALL 






Data 




Parameter-Name 


Type 


Type 


Description 


BLACKS (i ) 

i: TRACT 


PA 


R 


Black students in 
tract i 


DISTANCED, j) 
i: TRACT 


PA 


R 


Distance from tract i 
to school j 


j : SCHOOL 


SCHOOL 


IS 


C 


Schools 


SCHOOL-CAPAC(j) 


PA 


R 


School j student capacity 


j: SCHOOL 


STUDENTS (i,j) 
i: TRACT 


DV 


R 


Students in tract i 
assigned to school j 


j: SCHOOL 


THETA 


PA 


R 


Parametric quantity 


TRACT 


IS 


C 


School tracts 


WHITES (i ) 


PA 


R 


White students in tract i 



i: TRACT 

Figure 8. GXMP Session Displaying School Rezoning 
Model Parameters 
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*Type <CR> 


for 


Previous Menu 


1 


for 


Equation Operations 


2 


for 


Parameter Operations 


3 

*1 


to 


Solve Model 


*Type <CR> 


for 


Previous Menu 


1 


to 


Add Equation(s) to Model 


2 


to 


Delete Equation (s) from Model 


3 


to 


Renumber Equation (s) in Model 


4 


to 


Display Equation(s) in Model 


5 


to 


List Variables in Equations 


6 


to 


Compile Equations 


*4 


*Type <CR> 


to 


Return to Previous Menu 


1 


if 


Equation is a Constraint 


2 


if 


Equation is Objective Function 


*2 


*Type equation id (0 for all): 


#0 



OBJFCN-Id Equation 

10 MIN ( SUMO* , j ) [D ISTANCE ( i , j ) ^STUDENTS (i , j ) ] ) 

FOR i OVER TRACT, j OVER SCHOOL $ 

1 OBJFCN equations in model 

*Type <CR> to Return to Previous Menu 

1 if Equation is a Constraint 

2 if Equation is Objective Function 

*1 

*Type equation id (0 for all): 

#0 

CONSTR-Id Equation 

10 $UM(j)£STUDENTS(i,j)J = BLACKS(i) + WHITES (i ) 

FOR i OVER TRACT, j OVER SCHOOL $ 

20 SUM(i)lSTUDENTS(i,j)J = SCH00L-CAPAC( j ) 

FOR i OVER TRACT, j OVER SCHOOL $ 

30 SUM Ci )[( • 5 - THETA - WHITES(i )/(WHITES(i ) 

BLACKS Ci ) ) ) ^STUDENTS ( 1 , j )] <= 0 . 

FOR i OVER TRACT, j OVER SCHOOL $ 

40 SUMO ICC- 5 - THETA - BLACKS (i )/ (WHITES (i ) 

BLACKS (i ) ) )*STUDENTS(i ,j )] <? 0. 

FOR i OVER TRACT, j OVER SCHOOL $ 

50 STUDENTS (i, j )>= 0. 

FOR i OVER TRACT, j OVER SCHOOL $ 

5 CONSTR equations in model 



Figure 9. GXMP Session Displaying School Rezoning 
Model Equations 
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The primary strength of the GXMP modeling language is the indexing 
capability which allows equations to be specified symbolically and concisely. 

Note that each constraint equation in the school rezoning problem in Figure 6 
actually represents multiple constraint instances. Constraint 10, for example, 
symbolizes i constraint instances. This economy of expression due to the mathe- 
matical nature of the modeling language allows users to represent large models 
with very few equations. 

Furthermore, the language is robust in that it enforces a high degree 
of independence between the equations and the data. It is sufficient to observe 
that tracts and schools could be added or dropped from the parameter database 
for the school rezoning problem without having to make a single change to the 
equations in Figure 9. Similarly, equations could be added or deleted without 
altering the parameter data values. This would not be the case if a language 
required that each constraint be enumerated explicitly. Clearly there is a 
connection hetween model independence and the power of a modeling language. 

Once a model has been fully specified (parameters, parameter values, 
and equations), it is ready to be solved. The model solution process takes 
place as shown in Figure 10. The appropriate model abstraction instance for 
the model is located and a SOLVE predicate located within the abstraction. The 
SOLVE predicate lists which XMP routines need to be invoked and the order of 
invocation in order to effect a solution for the model. In a batch environment, 
a joh stream is established consisting of JCL commands, the appropriate XMP 
routines retrieved from the procedure library, and parameter data and equations 
retrieved from the parameter and equation databases. The job stream is submitted 
as a batch job whose result file is then processed interactively in a later 
session. In a totally interactive setting, the XMP routines are executed 
dynamically and the solution generated online. The obvious disadvantage of the 
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MR PROBLEM-SOLVER 



MP 

ABSTRACTION 




JOB CONTROL 



FORTRAN PROGRAM 
OF XMP CALLS 



MODEL DATA 



BATCH 

PROCESSOR 




Figure 10. The GXMP Model Solution Process for Batch Jobs 

latter approach is that online processing may be too time-consuming for all 
but small scale LP problems. Because our example is small, the interactive 
approach is used in this case. 

Once the model has been solyed yia the XMP routines, the solution 
reporter is invoked to report the results (Figure 11). The reporting of 
linear programming results has been a long-standing problem especially with 
large models having many variables. At the root of the problem is the naming 
convention that systems impose on the unfortunate user which often results in 
confusion as to which variable is which in the report. Names like "Variable 1" 
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* * * * * GXMP SOLUTION REPORTER * * * * * 

Model Type : LP-EON 

Model Instance: SCHOOL-REZONING 



Number of Linear constraints 
Number of Variables (incl. si 

Variable Identification 

STUDENTS (TRACT1 , JEFFERSON) 
STUDENTS (TRACT2, JEFFERSON) 
STUDENTS ( TRACT3 , JEFFERSON ) 
STUDENTS (TRACT4, WASHINGTON) 
STUDENTS ( TRACT5 , WASHINGTON ) 
STUDENTS(TRACT6, WASHINGTON) 
STUDENTS(TRACT7, JEFFERSON) 
STUDENTS (TRACT7, WASHINGTON) 
STUDENTS ( TRACT8 , HAMILTON ) 
STUDENTS (TRACT9, WASHINGTON) 
STUDENTS (TRACT9, HAMILTON) 
STUDENTS ( TRACT! 0 , HAMILTON ) 

***Remainder of variables are 

Constraint for Which Variable 
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ks & artificials): 49 

Val ue 

0. 45000000D+03 
0.40000000D+03 
0. 50000000D+03 
0.50000000D+03 
0.40000000D+03 
0.45000000D+03 
0. 15000000D+03 
0.30000000D+03 
0. 50000000D+03 
0. 50000000D+02 
0.35000000D+03 
0. 45000000D+03 

lacks/arti f i ci al s*** 

s Basic Value 



SCHOOL-CAPAC (HAMILTON) 
WHITE-RAT 10 (JEFFERSON) 
WHITE-RAT 10 (WASHINGTON) 
WHITE-RAT 10 (HAMILTON) 
TRACT-ASS IGNMENT ( TRACT6 ) 
TRACT-ASS IGNMENT ( TRACT9 ) 
TRACT- ASS IGNMENT (TRACT8 ) 



0. 30000000D+03 
0.55583337D+03 
0.91 6681 44D+00 
0.41075002D+03 
0.89166689D+02 
0.74008336D+03 
0.1 4825001 D+03 



Value of Objective Function: 
Constraint 

TRACT -ASS I GNMENT (TRACT1 ) 
TRACT-ASS I GNMENT (TRACT2 ) 
TRACT- ASS I GNMENT ( TRACT3 ) 
TRACT-ASS IGNMENT (TRACT4 ) 
TRACT- ASSI GNMENT (TRACT5 ) 
TRACT-ASS I GNMENT ( TRACT6 ) 
TRACT-ASSIGNMENT (TRACT7) 
TRACT-ASSIGNMENT(TRACT8) 
TRACT-ASS IGNMENT ( TRACT9 ) 
TRACT- ASS I GNMENT (TRACT1 0 ) 
SCHOOL-CAPAC( JEFFERSON) 
SCHOOL-CAPAC (WASHINGTON) 
SCHOOL-CAPAC (HAMILTON) 

WHITE- RATIO (JEFFERSON) 
WHITE-RATIO (WASHINGTON) 
WHITE- RATIO (HAMILTON) 
BLACK-RATIO (JEFFERSON) 
BLACK-RATIO (WASHINGTON) 
BLACK- RAT 1 0 CHAM I LTON ) 



-0.49650000D+04 

Dual Variable 

-0. 14000000D+01 
-0.27999998D+01 
-0.89999992D+00 
-0.1 3000000D+01 
-0. 40000001 D+00 
-0. 60000002D+00 
-0. 14000000D+01 
-0.17000001 D+01 
-0. 12000000D+01 
-0.1 5000001 D+01 
0. 19999993D+00 
O.OOOOOOOOD+OO 
0.500000 06 D+00 
O.OOOOOOOOD+OO 
O.OOOOOOOOD+OO 
O.OOOOOOOOD+OO 
O.OOOOOOOOD+OO 
O.OOOOOOOOD+OO 
O.OOOOOOOOD+OO 



Figure 11. GXMP Display of School Rezoning Model Solution 
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or "Demand(3,4)" are just not descriptive enough in most cases. Furthermore, 
users are often required to enumerate each name as input which can be extremely 
tedious for large problems. Imagine having to input "DEMAND(i ,j )" for i and 
j equal to 100. 

The GXMP subverts this problem largely through the power of its modeling 
language. The user need only enter each parameter name in the model once, 
generically as it were. Thus, "DEMAND(i ,j )" is the only GXMP entry necessary 
for a parameter representing the demand from city j for a product at city i. 
After the model with this parameter is formulated and solved, the solution 
(assuming DEMAND(i,j) is a decision variable) is displayed with index values 



substituted for i and j, e.g.: 




DEMAND (DALLAS, SEATTLE) 


1124. 


DEMAND (DALLAS, LA) 


3962. 


DEMAND (TUCSON, SEATTLE) 


836. 



The decision variables are fully documented at the back end with this convention 
while requiring a minimum of input at the front end. The user supplies only 
the names (15 characters or less) for each "generic" variable. The same conven- 
tion is employed in prompting the user for parameter data values once the param- 
eter names have been defined. Thus, usage is consistent throughout the process 
from model formulation to model solution. 

Another user-friendly feature of this approach is the ability to focus 
on a subset of the solution. This can be done in the solution reporter by 
specifying explicitly which variables the user wants to see. Thus, one can 
specify STUDENTS (TRACT5, WASHINGTON) to see only that value, or more useful, 
specify STUDENTS(*, WASHINGTON) to see the number of students from each tract 
who are to be bused to the Washington school. The * "wild card" character 
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provides a powerful feature for looking at only the parts of the solution which 
a user is particularly interested in. The advantages of this approach over 
wading through a massive printout to find a limited set of solution variables 
are readily apparent, especially for large models with many decision variables. 

Notice that in addition to fully identifying the decision variables in 
the solution basis, GXMP also provides an equivalent capability for the dual 
variables. This is accomplished by assigning each equation an equation name in 
addition to a unique numeric identification. (Note: GXMP has not yet been 
modified to display these names which is why they do not appear in Figure 9.) 
Thus equation CONSTR 10 is TRACT-ASSIGNMENT, CONSTR 20 is SCH00L-CAPAC and so 
forth. Thus the dual variables can be associated with their corresponding 
equation appropriately indexed as in Figure 11. This feature helps document 
the equations and improves the readability of the solution report. 

5. CONCLUSIONS AND FURTHER RESEARCH 

The development of the GXMP system has been scheduled in three phases. 
This paper has discussed the results of the first phase which is the design 
and implementation of a model management system for LP models. The current 
version of GXMP is essentially a user-friendly top end for LP software with 
built-in capabilities for model management. Further work is necessary to make 
fuller use of these features. 

The second phase is concerned with extending the knowledge-based nature 
of the system. Although the apparatus for a knowledge-based modeling system 
is already in place, many theoretical issues remain to be studied before imple- 
mentation can occur. In particular, the following areas need to be resolved: 

1. What kinds of knowledge to represent about models. 

2. How to represent this knowledge (the model abstraction needs to be 

defined more carefully). 
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3. What kind of inferencing and pattern-matching technique(s) to use 
with regard to models. 

The third phase of 6XMP development is to extend the system to a general- 
ized model management system (GMMS). This involves incorporating other classes 
of models (e.g.: simultaneous equation estimation, discrete event simulation, 

etc.) into the knowledge-based framework. This will test the versatility of 
the model abstraction concept and may entail extensions to the modeling language 
and compiler. Another important issue to be addressed in this stage is the 
development of a technique for linking models to form composite models as well 
as the inverse operation of decomposing models into simpler components which 
can then be relinked after solution. 
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